<!DOCTYPE HTML>
<html lang="en">
<head>
  <meta name="copyright" content=
  "Copyright (c) IBM Corporation and others 2000, 2011. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page.">
  <meta charset="utf-8">
  <link rel="STYLESHEET" href="../book.css" type="text/css">
  <script src="PLUGINS_ROOT/org.eclipse.help/livehelp.js"></script>
  <title>Build</title>
</head>
<body>
  <h1 class="Head">Build</h1>
  <p class="Para">On the <a class="command-link" href=
  'javascript:executeCommand("org.eclipse.ui.window.preferences(preferencePageId=org.eclipse.ui.preferencePages.BuildOrder)")'>
  <img src="PLUGINS_ROOT/org.eclipse.help/command_link.svg" alt="command link"> <strong>General &gt; Workspace &gt;
  Build</strong></a> preferences page, you can configure how the projects inside the workspace will be built.</p>
  <table class="border">
    <thead>
      <tr>
        <th>
          <p class="Para">Option</p>
        </th>
        <th>
          <p class="Para">Description</p>
        </th>
        <th>
          <p class="Para">Default</p>
        </th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td>Build automatically</td>
        <td>If this option is turned on, then the Workbench will perform an automatic build whenever a modified
        resource is saved.</td>
        <td>On</td>
      </tr>
      <tr>
        <td>Save automatically before build</td>
        <td>If this option is selected, when a manual build is performed the Workbench will automatically save all
        resources that have been modified since the last build was performed.<br></td>
        <td>Off<br></td>
      </tr>
      <tr>
        <td>
          <p class="Para">Use default builder order</p>
        </td>
        <td>
          <p class="Para">This option allows the platform to computes the build ordering. Turning off this option
          enables access to the projects list, the ordering of which can be manipulated.</p>
          <p>Often the order in which projects are built is important. For example, if one project requires the Java
          classes which were defined in another project, the first project must be built after its prerequisite classes
          have been built. The Workbench allows users to explicitly define the order in which projects are built.
          Alternatively, users can let the platform compute the build order by interpreting project references as
          prerequisite relationships. The build order is applied for both building the entire workspace or for a group
          of projects.</p>
        </td>
        <td>On</td>
      </tr>
      <tr>
        <td>
          <p class="Para">Project build order</p>
        </td>
        <td>
          <p class="Para">This option allows you to select projects and use the <b>Up</b> and <b>Down</b> buttons to
          change the build order. Add and remove projects in the build order using the <b>Add Project</b> and <b>Remove
          Project</b> buttons. Projects removed from the build order <i>will</i> be built, but they will be built after
          all projects in the build order are built.</p>
        </td>
        <td></td>
      </tr>
      <tr>
        <td>
          <p class="Para">Max iterations when building with cycles</p>
        </td>
        <td>
          <p class="Para">This preference allows you to deal with build orders that contain cycles. Ideally, you should
          avoid cyclic references between projects. Projects with cycles really logically belong to a single project,
          and so they should be collapsed into a single project if possible. However, if you absolutely must have
          cycles, it may take several iterations of the build order to correctly build everything. Changing this
          preference will alter the maximum number of times the workbench will attempt to iterate over the build order
          before giving up.</p>
        </td>
        <td>10</td>
      </tr>
      <tr>
        <td>Max simultaneous project builds</td>
        <td>
          Under some safe circumstances, the workspace can chose to build independent projects in parallel. In such
          case, this preference controls the maximum amount of jobs/threads that will be running builds in parallel. A
          value of <code>1</code> indicates that build won't be parallelized and keeps the legacy behavior.
          <p>The optimal value depends on your machine and workspace projects specificities. We do recommend to try
          relatively low values (such as <code>4</code>) first which already allow to save time, when projects allow
          it, while not risking to overload your CPU.</p>
        </td>
        <td>1</td>
      </tr>
    </tbody>
  </table>
  <h3 class="related">Related Reference</h3><a href="ref-5.htm">Builds</a><br>
  <a href="ref-59.htm">Project menu</a>
</body>
</html>
